Release engineering generally concerns building, packaging, and distributing a content item in a reproducible and consistent manner. In the context of software development, release engineering can involve creating and configuring processes and tools to automate the compilation, testing, packaging, and deployment of source code into finished products or software components (e.g., libraries, plug-ins, drivers, or other stand-alone units of software). Release engineering can also include distribution, monitoring, and maintenance of released products or components.
An important tool for coordinating various release engineering tasks is a version control system (VCS) (sometimes also referred to as a revision control system (RCS) or as a source code control system (SCCS) if operated only for source code and related data). A VCS can track the history and attribution of a content item or collection of content items over time and enable retrieval of a specific version of the content item or collection. A VCS can store various types of content, such as metadata, text, image, video, audio, or other binary files, to a repository (sometimes referred to as a repo) that is accessible to multiple users to allow the users to work on the content concurrently and, preferably, in a non-blocking manner. For example, a VCS can provide a content producer her own sandbox of the content, share her work in progress with other users and request feedback from the users, update an authoritative version of the content (sometimes referred to as the trunk, master, mainline, or baseline) with her work in progress but ensure the work does not conflict with others, and facilitate merging of changes and synchronization of the content.
One of the responsibilities of release engineering can include establishing work flows or processes regarding how development, quality assurance, and operations teams should use a VCS during the development and release cycle of a software project. For example, a work flow may define a branching and release strategy, such as maintaining a single branch and cutting releases from this branch (sometimes referred to as trunk-based development) or maintaining a hierarchy of branches based on their relative stability (e.g., alpha, beta, stable), “graduating” branches after they achieve a specified degree of maturity, and cutting releases from the most stable branch. A development and release work flow may also dictate how often to commit source code or how often to release new versions of a product. One popular development and release strategy, known as continuous integration or continuous delivery/deployment (CI/CD), encourages merging of source code early and often during development, such as once or several times a day, and providing releases every day or every few days. Merge conflicts inevitably arise when multiple users are working on a common project; and over time integrating code can require intensive human labor such as due to the complexities of code dependencies, the necessity for collaboration across multiple development teams and projects, and the assurance that merged code functions properly via robust testing requirements. CI/CD ensures that parallel tracks of development do not veer too far apart from one another; and CI/CD essentially decomposes a big problem, e.g., integrating and testing source code from weeks or months of development on multiple branches, into smaller, more manageable pieces, e.g., merging and testing source code from daily work on different branches.
Observance of the principles of CI/CD can be straight-forward when a project has a uniform development, testing, and release cycle or when a product consists of discrete and substantially or completely self-contained modules but many software architectures comprise interdependent components that may require different periods of time for development and testing. For example, a conventional web browser typically includes user interface (UI) functionality for handling user input (e.g., menu toolbar, address bar, search toolbar, bookmarks, etc.), rendering functionality for interpreting mark-up language, scripts, and stylesheets and generating a layout corresponding to these elements, and an interface between the UI functionality and the rendering functionalities. These web browser components are often highly integrated with one other and dependent on a common set of code (e.g., display/graphics or network interfaces. While it may be possible to develop, test, and release new versions of the web browser UI functionality over short periods of time, it is unlikely that development of the UI-rendering interface and rendering functionality can run on the same schedule. Various types of software may face the same issue, such as an anti-virus program having scanning functionality that has a different life-cycle from other program features or a client application, of an online synchronized content management system (CMS), whose synchronization functionality may require different lengths of time for development and testing than other functionalities.